Particular embodiments generally relate to extensible applications.
In an “extensible” application, a developer of an application may enable third parties to “extend” the application with additional functionality through the application's “extension framework,” for example, by adding third party developed plug-ins or other similar add-on technologies to the application. Such extensibility is particularly useful for extending a graphical user interface (GUI) of an application, enabling third party plug-ins to add their own views and/or other GUI components to the application by extending certain well-defined “extension points” exposed by the application's extension framework. One example of a GUI extension point that may be exposed by an application's extension framework is a capability to add an additional tab panel to a strip of tabs panels that make up a main panel of the application. In “fully” extensible applications, these third party plug-ins can also further define new GUI extension points that could then be extended by yet other third party plug-ins. However, the flexibility provided by such fully extensible applications also introduces complexities in navigating the GUI of such applications because the application itself simply has no knowledge of new GUI extensions from extension points of the application itself or from additional extension points further provided by third party plug-ins.
For example, in certain situations, it may be desirable in a fully extensible application to provide navigational links to certain views or parts of the GUI that provide more information about a particular object or concept. A third party developer of a plug-in may desire to provide a user the capability to navigate (e.g., via a link) from a GUI component of its plug-in to another part of the application's GUI (not necessarily written by the developer itself). For example, the developer may desire to offer a plug-in extension showing a health view for a set of objects giving high level health statistics of each object. The developer may also desire to provide a navigational link (e.g., a “More Details” link) in this view for each object so that the user can navigate to an “Issues” view to perform troubleshooting analysis. This “Issues” view for an object may have already been developed and added to the application by another third party developer as an extension. However, because the application itself is unaware of the Issues view that has been added as an extension, the third party developer is unable to request the application to navigate to the Issues view from a GUI component of the developer's own plug-in.
The inability of the application to navigate to the Issues view stems from the “static” nature of the application's “navigation framework,” which hard-codes the extension structure of the application and pre-defines how a user can navigate within different parts of the application. Such “static” navigation frameworks limit the flexibility of third party enhancements to an application. As illustrated above, because the navigation framework above cannot access GUI components (or other objects) of the main display of a plug-in, a plug-in developed by one third party cannot include a link (or other GUI component) within its main display which, when selected, causes a tab panel (or other GUI component) nested or embedded in the main display of another plug-in developed by a different third party to be displayed. In contrast to the static navigation frameworks described above, in an extensible application having a more flexible navigation framework, the navigation framework would enable a user to request navigation from any component (e.g., a view) to any other component. The navigation framework would accommodate arbitrary jumps to any component of any plug-in even if the component is arbitrarily nested within other components, has not been loaded into the application at the time of the navigation request or is subsequently moved to a different location within the GUI.